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(57) Abstract: The invention concerns a method for loading an applet in a smart card (2a), using two loading programmes, a so-called 
In-loader (IL), stored in the card, and Off-loader, respectively. The invention is characterised in that two specific communication 
protocol layers are provided, one in a terminal (1) hosting the card reader, the other in the card. Said layers include in particular 
intelligent agents enabling the card to provide a WEB client/server and a CGI gateway functional capability. The method comprises 
at least one step during which a HTTP request is sent to the card, to address a HTML page, a step which consists in retrieving pa- 
rameter] sing data transported by a HTML form and a step which consists in executing a second loading programme (TL) using the 
CGI functional capability to load the applet. 

(57) Abr6ge : L* invention concerne le chargemcnt d'une "applet" dans une carte a puce (2a), a Taide de deux programmes de char- 
gement, dits "In-loader" (IL), stocke" dans la carte, ct "Off-loader" (OL), respectivement. Selon T invention, on pr6voit deux couches 
protocolaires de communication specifiques, Tune dans un terminal (1) he'bergeant le lecteur de la carte, l'autre dans la cane. Ccs 
couches comprennent notamment des agents intelligents permettant a la carte d'offrix une fonctionnalite' de client/serveur "WEB" et 
de passerelle "CGI". Le proc^de* comprend au moins une 6tape pendant laquelle une requete "HTTP" est envoyee a la carte, pour 
adresser une page "HTML", une Stape de recuperation de donnccs dc param£trage v£hicuI6es par un formulaire "HTML" et une 
e*tape d'ex^cution du second programme de chargement (IL), par misc cn oeuvre de la fonctionnalitC "CGI", pour charge V "Applet ". 
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En ce qui concerne les codes a deux lettres et autres abbrevia- 
tions, se referer aux "Notes explicates relatives aux codes et 
abreviat ions" figurant au debut de chaque numero ordinaire de 
la Gazette du PCT. 
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PROCEDE DE CHARGEMENT D'UNE PIECE DE LOGICIEL DANS UNE 
CARTE A PUCE, NOTAMMENT DU TYPE DIT "APPLET" 

L'invention concerne un procede de chargement d'une piece de 
logiciel dans une carte a puce. 

Elle s'applique plus particulierement au chargement d'une piece de 
5 logiciel appelee en frangais "appliquette", plus connue sous le terme anglo- 
saxon d' "applet". II s'agit d'une application ecrite en langage "JAVA" 
(marque deposee). Ces applications, generalement peu volumineuses, sont 
independantes des architectures des systemes sur lesquelles elles sont 
implantees. Elles peuvent done fonctionner sur n'importe quel systeme 

10 informatique, dans la mesure ou celui-ci implemente le concept dit de 
"machine virtuelle JAVA" ("Java Virtual Machine"). Une application ecrite en 
langage JAVA est en general traduite en un langage intermediate dit "Byte 
Code". La machine virtuelle JAVA precitee constitue un interpretateur de ce 
"Byte Code", de maniere a etre executee directement sur un systeme cible, 

15 hote de ladite machine virtuelle. 

Generalement, les architectures de systeme sur lesquelles tourne 
ce type duplications sont du type dit client-serveur. Dans ce cas, on parle 
egalement de "servlet" pour une application stockee sur un systeme serveur 
et "applet" pour une application stockee sur un systeme client. Dans ce qui 

20 suit, on utilisera le terme "applet" de fagon generique. 

Des pieces de logiciel, se presentant sous la forme d 1 "applet" qui 
vient d'etre rappelee, dans la mesure ou la quantite de code n'est pas trop 
volumineuse, peuvent etre stockees dans une memoire non volatile presente 
sur une carte a puce, au meme titre que toute autre application. 

25 Aussi, le procede selon ('invention est plus particulierement 

concerne par un terminal ou station d'utilisateur muni d'un lecteur de carte a 
"puce". 
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Dans le cadre de Pinvention, le terme "terminal" doit etre compris 
dans un sens general. Le terminal precite peut etre notamment constitue par 
un ordinateur personnel fonctionnant sous divers systemes d'exploitation, 
tels WINDOWS ou UNIX (tous deux etant des marques deposees). II peut 
5 etre aussi constitue par une station de travail, un ordinateur portable ou un 
terminal de carte dit d6di6. 

Dans Tetat actuel de la technique, le chargement d'une "applet" sur 
une carte a puce (encore appele telechargement) se fait grace a deux 
programmes specifiques. Ces programmes sont generalement connus sous 
10 les termes anglo-saxons "Off-Loader", pour le premier, et "In-Loader", pour 
le second. Le programme "Off-Loader" s'execute sur le terminal et le 
programme "In-Loader" s'execute dans la carte a puce. Les programmes de 
chargement "Off-Loader" et "In-Loader" communiquent entre eux au travers 
d'une liaison normalisee de type ISO 7816-3, protocole universellement 
15 retenu pour les communications entre une carte a puce et son terminal hote. 
Ce protocole met en oeuvre une suite d'echanges generalement 
proprietaires (commandes d'un type dit "APDU" qui seront explicitees ci- 
apres) afin de realiser le chargement d'une "applet". 

La figure 1A annexee a la presente description illustre de fa?on 
20 schematique I'architecture mise en oeuvre pour le chargement d' "applets" 
dans une carte a puce selon Tart connu. 

Le terminal 1 stocke un premier programme specifique de 
chargement ("Off-Loader"), reference OL. II communique avec une carte a 
puce 2, via un lecteur de carte a puce 3. Les transmissions s'effectuent selon 
25 un protocole de communication normalise, faisant appel aux commandes 
precitees, protocole qui sera detaille ci-apres. 

La carte a puce 2, pour sa part stocke un second programme 
specifique de chargement ("In-Loader"), reference IL. 

Un premier inconvenient de ce proc§de est que les programmes IL 
30 et OL doivent etre apparies pour pouvoir communiquer entre eux. II s'ensuit 
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que s'ils sont d'origines differentes, ils ne sont pas, a priori, compatibles. 
Cette caracteristique est liee au jeu de commandes a utiiiser. 

Un deuxieme inconvenient est du au fait que les communications 
s'effectuent selon le protocole ISO 7816 precite. En effet, celui-ci impose une 
5 proximite physique entre les programmes OL et IL. II s'ensuit que le 
programme OL doit generalement s'executer directement sur le terminal 1 et 
non, par exemple, sur un autre terminal ou un serveur eloigne. 

Or, avec I'essor spectaculaire du reseau Internet, un nombre 
toujours croissant de terminaux sont connectes a ce reseau, notamment 

io pour pouvoir etre en liaison avec des serveurs eloignes, de type "WEB". II 
serait done interessant, par exemple, de pouvoir stocker la partie "Off- 
Loader" OL des programmes de chargement d' "applets" sur un serveur 
"WEB" connecte a ce reseau. Les "applets" a charger sur une ou plusieurs 
carte(s) a puce pourraient d'ailleurs etre aussi stockees sur ce serveur ou 

15 sur un ou plusieurs autres serveurs de ce type. 

Dans I'etat actuel de la technique, ce mode operatoire bute sur une 
double impossibilite. La premiere a deja ete evoquee : la norme retenue pour 
les communications entre le terminal et la carte a puce impose a priori une 
proximite physique entre la localisation des programmes "Off-Loader", OL, et 

20 "In-Loader", IL. 

D'autre part, les transmissions entre deux systemes, par exemple 
un terminal et un serveur eloigne, via le reseau Internet, font appel a des 
protocoles de type Internet. Dans I'etat actuel de la technique, il n'est pas 
possible de realiser des communications directes entre une carte a puce et 

25 le reseau Internet, comme il va I'etre explicite egalement. 

Dans le cadre de I'invention, le terme "reseau Internet" englobe, 
outre le reseau Internet proprement dit, les reseaux prives d'entreprises ou 
similaires, du type dit "intranet", et les reseaux les prolongeant vers 
I'exterieur, du type dit "extranet", et de fagon generale tout reseau dans 

30 lequel les echanges de donnees s'effectuent selon un protocole du type 
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Internet. Dans ce qui suit un tel reseau sera appele de fagon generique 
"reseau Internet". 

On va tout d'abord rappeler brievement I'architecture generale d'un 
systeme duplication a base de carte a puce, relie a un reseau Internet, par 
5 reference aux figures 1 B et 1 C. 

Un systeme duplication a base de carte a puce comporte 
generalement les elements principaux suivants : 
une carte a puce ; 

un systeme hote constituant le terminal precite ; 
10 - un reseau de communication, a savoir le reseau Internet dans 

Implication preferee ; 

et un serveur d'application connecte au reseau Internet. 
La figure 1B illustre schematiquement un exemple d'architecture de 
ce type. Le terminal 1 , par exemple un ordinateur individuel, comporte un 
15 lecteur 3 de carte a puce 2. Ce lecteur 3 peut etre ou non physiquement 
integre dans le terminal 1. La carte a puce 2 comporte un circuit integre 20 
dont des connexions d'entrees-sorties affleurent en surface de son support 
pour autoriser une alimentation en energie electrique et des communications 
avec le terminal 1 . Ce dernier comprend des circuits d'acces 1 1 au reseau 
20 Internet/?/. Ces circuits peuvent etre constitues par un modem pour se 
connecter a une ligne telephonique commutee ou a une voie de 
communication a plus haut debit : reseau numerique a integration de 
services ("RNIS"), cable ou liaisons par satellite, etc. Les circuits 11 
permettent de se connecter au reseau Internet fl/, directement ou via un 
25 prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la 
terminologie anglo-saxonne). On peut egalement avoir recours a un systeme 
intermediaire tel qu*un "proxy" ou un systeme d'isolation dit "firewall" ("pare- 
feu" ou encore appele "garde barriere"). 

Le terminal 1 comprend naturellement tous les circuits et organes 
30 necessaires a son bon fonctionnement, et qui n'ont pas ete represents 
dans un but de simplification du dessin : unite centrale, memoires vive et 
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fixe, memoire de masse & disque magnetique, lecteur de disquette et/ou de 
CedeRorn, etc. 

Habituellement, )e terminal 1 est aussi relie a des peripheriques 
ciassiques, integres ou non, tels un ecran de visualisation 5, un clavier 6a et 
5 une souris 6b, etc. 

Le terminal 1 peut etre mis en communication avec des serveurs ou 
tous systemes informatiques connectes au reseau Rl, dont un seul, 4, est 
illustre sur la figure 1A. Les circuits d'acces 11 mettent le terminal 1 en 
communication avec les serveurs 4 grace a un logiciel particulier 10, appele 
w navigateur "WEB", ou "browser" selon la terminologie anglo-saxonne. Celui- 
ci permet d'acceder a diverses applications ou fichiers de donnees repartis 
sur I'ensemble du reseau Rl, generalement selon un mode "client-serveur". 

Habituellement, les communications sur les reseaux s'effectuent 
conformement a des protocoles repondant a des standards comprenant 
15 plusieurs couches logicielles superposees. Dans le cas tfun reseau Rl de 
type Internet, les communications s'effectuent selon des protocoles 
specifiques a ce type de communications, qui seront detailles ci-apres, mais 
qui comprennent egalement plusieurs couches logicielles. Le protocole de 
communication est choisi en fonction de I'application plus particulierement 
20 visee: interrogation de pages "WEB", transferts de fichiers, courrier 
electronique (e-mel, ou "e-mail" selon la terminologie anglo-saxonne), 
forums ou "news", etc. 

[.'architecture logique du systeme comprenant un terminal, un 
lecteur de carte a puce et une carte a puce, est representee 
25 schematiquement par la figure 1C. Elle est decrite par la norme ISO 7816, 
qui elle-meme comportent plusieurs sous-ensembles : 

ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et le 
marquage des cartes ; 

ISO 7816-3, en ce qui concerne le transfer! de donnees entre 
30 le terminal et la carte a puce ; et 
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ISO 7816-4, en ce qui concerne la structure du jeu d'ordres et 
le format des commandes. 

Sur la figure 1C, du cote terminal 1, on n'a represents que les 
couches repondant a la norme ISO 7816-3, referencees 101, et un 
5 gestionnaire d'ordres "APDU" (norme ISO 7816-4), reference 102. Du cote 
carte a puce 2, les couches repondant a la norme ISO 7816-3 sont 
referencees 200 et le gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est 
reference 201 . Les applications sont referencees Ai , .... Aj, A n ; n etant le 
nombre maximum d'applications presentes sur la carte a puce 2. 

10 Une application, A,; presente dans la carte a puce 2, dialogue avec 

le terminal 1 au moyen d'un jeu d'ordres. Ce jeu presente typiquement des 
ordres d'ecriture et des ordres de lecture. Le format des ordres est connu 
sous I'abreviation anglo-saxonne de "APDU" (pour "Application Protocol 
Data Unit"). II est defini par la norme ISO 7816-4 precitee. Une "APDU" de 

15 commande est notee "APDU. command' et une "APDU" de reponse est 
notee "APDU. response". Les "APDU" sont echangees entre le lecteur de 
carte et la carte a puce au moyen d'un protocole specifie par la norme ISO 
781 6-3 precitee (par exemple en mode caractere : T=0 ; ou en mode bloc : 
T=1). 

20 Lorsque la carte a puce 2 inclut plusieurs applications distinctes, 

comme illustre sur la figure 1C, on parle de carte multi-applicative. 
Cependant, le terminal 1 ne dialogue qu'avec une seule application a la fois. 
Une application Aj se presente, par exemple, sous la forme d'une "applet" 
qui peut etre enregistree initialement, ou encore chargee a partir du terminal 

25 1. Pour ce faire, comme illustre par la figure 1A, on a recours a un 
programme "Off-Loader", OL, enregistre dans le terminal 1 et a un 
programme "In-Loader", IL, qui forme I'une des applications A; de la carte a 
puce 2. 

La selection d'une application particuliere Aj est obtenue a I'aide 
30 d'une "APDU" du type selection ("SELECT"). Une fois ce choix effectue, les 
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"APDU" qui le suivent sont achemines vers cette application. Une "APDU 
SELECT" nouvelle a pour effet d'abandonner Tapplication en cours et d'en 
choisir une autre. Le sous-ensemble logiciel gestionnaire des "APDU" 201 
permet de choisir une application particuliere A\ dans la carte a puce 2, de 
5 memoriser ('application ainsi choisie, et de transmettre et/ou recevoir des 
"APDU" vers et depuis cette application. 

En resume de ce qui vient d'etre decrit, la selection d'une 
application Aj et le dialogue avec celle-ci s'effectuent par echanges d'ordres 
"APDU". On suppose que les applications Aj sont des applications 

w conventionnelles, que Ton appellera ci-apres "GCA" (pour "Generic Card 
Application" ou application de carte generique). 

Ce mode operatoire explique que les programmes OL et IL doivent 
etre apparies, pour que les ordres "APDU" echanges puissent etre 
compatibles et compris par ces deux applications. 

*5 Ces rappels etant effectues, il est a noter que la carte a puce 2 ne 

peut communiquer directement avec les navigateurs standards du 
commerce, sauf a modifier le code de ces derniers. 

En outre, et surtout, les cartes a puce actuelles, qui par ailleurs sont 
conformes aux standards et normes rappeles ci-dessus, ont une 

20 configuration materielle et logicielle qui ne permet pas non plus de 
communiquer directement avec le reseau Internet. En particulier, elles ne 
peuvent recevoir et transmettre des paquets de donnees, selon Tun ou 
I'autre des protocoles utilises sur ce type de reseau. II est done necessaire 
de prevoir une piece de logiciel additionnelle, implantee dans le terminal 1 , 

25 generalement sous la forme de ce qui est appele un "plug-in", selon la 
terminologie anglo-saxonne. Cette piece de logiciel, qui porte la reference 12 
sur la figure 1B, effectue Tinterface entre le navigateur 10 et la carte 2, plus 
precisement les circuits electroniques 20 de cette carte 2. 
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L'invention vise a pallier les inconvenients des procedes et 
dispositifs de Tart connu, et dont certains viennent d'etre rappeles, tout en 
repondant aux besoins qui se font sentir. 

Selon une premiere caracteristique de l'invention, les deux 
5 programmes de chargement, OL et IL ne sont plus dependants I'un de 
I'autre. En d'autres termes, ils n'ont plus a etre apparies pour etre 
compatibles. 

Selon une deuxieme caracteristique de (Invention, la partie OL des 
programmes de chargement n'a plus a etre stockee obligatoirement dans le 

10 terminal, c'est-a-dire en relation de proximite physique avec la seconde 
partie IL. Tout au contraire, le programme OL peut etre stocke sur un 
serveur eloigne, connecte au terminal via un reseau de type Internet. 

Pour ce faire, et selon une autre caracteristique de l'invention, la 
carte a puce se comporte comme un serveur/client de type "WEB" pour le 

15 terminal qui lui est associe. 

Pour atteindre ce but, on prevoit une couche de logiciel de 
communication specifique dans la carte a puce et son pendant dans le 
terminal. Le terme "specifique" doit etre entendu comme specifique au 
procede de l'invention. En effet, ces couches de communications, dites 

20 specifiques, sont banalisees quelle que soit ('application consideree. Elles 
n'interviennent que dans le processus d'echanges de donnees 
bidirectionnels entre la carte a puce et le terminal, d'une part, et la carte a 
puce et le reseau, d'autre part. 

Les couches logicielles de communication specifiques comprennent 

25 notamment des composants logiciels, dits "agents intelligents", permettant 
en particulier des conversions de protocoles. Les agents intelligents seront 
appeles ci-apres plus simplement "agents". II existe des agents appareilles 
dans les couches de communication specifiques respectives associees au 
terminal et a la carte a puce. Selon le procede de l'invention, il s'etablit des 

30 sessions entre agents appareilles. 
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Selon une airre caracteristique, le procede de invention rend 
possible I'activation duplications de type conventionnel, c'est-a-dire du type 
"CGA" precite, localisees dans une carte a puce, sans devoir les modifier en 
quoi que ce soit. 

5 Pour ce faire, on prevoit un ou plusieurs agents intelligents 

particuliers dits traducteurs de script, qui regoivent des requetes d'un 
navigateur et les traduisent en ordres "APDU" comprehensibles par 
('application de type "CGA". De ce fait, on implante dans la carte a puce une 
fonction similaire a celle connue par ailleurs sous la denomination "CGI" 
w dans les serveurs "WEB" classiques. Cette fonction permet de mettre en 
oeuvre une application dans la carte a puce par un protocole Internet de type 
"HTTP". 

Le chargement d'une "applet" dans la carte a puce peut s'effectuer 
par cette interface "CGI". La partie IL du programme de chargement est 

15 considere comme etant un script de commandes, que Ton appellera "cgi- 
script", attache a la fonctionnalite serveur "WEB" offerte par la carte a puce. 
Les echanges entre les programmes OL et IL peuvent se derouler avec 
I'aide de formulaires classiques en langage "HTML" ou "forms" selon la 
terminologie anglo-saxonne. 

20 Tout en conservant les normes ISO precitees pour les 

communications entre terminal et carte a puce, via le iecteur de carte a 
puce, le procede selon Tinvention permet des echanges entre les parties de 
programmes de chargement OL et IL en faisant appel au protocole de 
communication Internet "TCP/IP", la partie OL et les "applets" a charger 

25 pouvant etre stockees en local ou dans un serveur eloigne. 

L'invention a done pour objet principal un procede de chargement 
d'une piece de logiciel dans une carte a puce a partir d'un terminal connecte 
a ladite carte a puce par I'intermediaire d'un Iecteur de carte a puce 
permettant des communications selon un premier protocole determine, ledit 
30 chargement s'effectuant par la mise en oeuvre et la cooperation de premier 
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et second programmes de chargement, ledit second programme de 
chargement etant stocke dans ladite carte a puce, caracterise en ce qu'il 
comprend au moins les phases suivantes : 

a/ une premiere phase preliminaire consistant a implanter, dans 
ladite carte a puce, une premiere piece de logiciel, formant une couche 
protocolaire de communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans 
ledit terminal, une seconde piece de logiciel, formant une couche 
protocolaire de communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel comprennent 
en outre au moins une paire de premieres entites logicielles appariees, 
chacune desdites entites cooperant Tune avec I'autre de maniere a 
permettre I'etablissement d'une session d'echanges de donnees 
bidirectionnels entre au moins ledit terminal et ladite carte a puce, de 
maniere a ce que ladite carte a puce offre la fonctionnalite d'un client/serveur 
"WEB" ; 

en ce qu'il comprend une troisieme phase preliminaire consistant a 
implanter dans ladite carte a puce au moins une deuxieme entite logicielle, 
apte a interpreter une suite destructions et a la traduire en une suite 
d'ordres, de maniere a cooperer avec ladite seconde piece de logiciel 
specifique pour que ladite carte a puce offre une fonctionnalite d'interface 
passerelle dite "CGI", la dite carte a puce comprenant au moins une desdites 
suites destructions associee au dit second programme de chargement ; 
et en ce qu'il comprend au moins les etapes suivantes : 
1/ ouverture d'une premiere session d'echanges de donnees 

entre au moins ledit terminal et ladite carte a puce, pour la transmission 
d'une requete pour que ledit premier programme de chargement 
recupere des donnees de parametrage de chargement fournies par 
ledit second programme de chargement ; 
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21 ouverture d'une deuxieme session d'echanges de donnees 

entre ladite carte a puce et au moins ledit terminal pour transmettre 
lesdites donnees de parametrage de chargement au dit premier 
programme de chargement, lesdites donnees de parametrage 
comportant une reference aux dites instructions associees au dit 
second programme de chargement ; et 

3/ ouverture d'une troisieme session d'echanges de donnees 
entre au moins ledit terminal et ladite carte a puce, pour la soumission d'un 
fichier de chargement prenant en compte lesdites donnees de parametrage 
de chargement, ledit fichier comprenant des donnees representant ladite 
piece de logiciel a charger; interpretation de ladite suite destructions 
associee au dit second programme de chargement, par mise en oeuvre de 
ladite fonctionnalite "CGI", de maniere generer une suite d'ordres transmise 
au dit second programme de chargement, a executer ce programme et a 
obtenir ledit dechargement de ladite piece de logiciel. 

L'invention va maintenant etre decrite de fagon plus detaillee en se 
referant aux dessins annexes, parmi lesquels : 

la figure 1A illustre schematiquement un exemple de realisation 
d'une architecture permettant le chargement d'une "applet" dans une 
carte a puce selon Tart connu ; 

les figures 1B et 1C illustrent les architectures materielle et 
logique, respectivement, d'un exemple de systeme d'application a 
base de carte a puce connecte a un reseau Internet selon Tart 
connu, ; 

la figure 2 illustre schematiquement un exemple de systeme 
d'application a base de carte a puce selon l'invention, cette derniere 
agissant en tant que client/serveur "WEB" ; 

la figure 3 est un diagramme d'etats d'une session entre des 
entites logicielles dites agents intelligents, selon un aspect de 
l'invention ; 
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la figure 4 illustre de fagon simplifiee ('architecture logique d'un 
systeme selon ('invention dans iequel la carte a puce comprend des 
agents intelligents ; 

la figure 5 illustre de fagon simplifiee I'architecture logique d'un 
5 systeme selon invention dans lesquels la carte a puce comprend 

des agents intelligents traducteurs de scripts ; 

la figure 6 illustre schematiquement un exemple de realisation 
d'une architecture permettant le chargement d'une "applet" dans une 
carte a puce selon ('invention ; 
10 - la figure 7 illustre la structure d'un fichier de chargement d'une 

"applet" pouvant etre en ceuvre par le procede selon I'invention ; 

la figure 8 illustre schematiquement les phases principales du 
procede de chargement d'une "applet" dans une carte a puce selon 
un premier exemple de realisation pratique ; 
15 - 'a figure 9 illustre schematiquement les phases principales du 

procede de chargement d'une "applet" dans une carte a puce selon 
un deuxieme exemple de realisation pratique ; 

les figures 9 et 10 illustrent deux exemples de formulaires en 
langage "HTML" utilisables par le procede de chargement d'une 
20 "applet" dans une carte a puce selon I'invention, pour la mise en 

oeuvre des methodes dites "GET" et "POST", respectivement ; et 

les figures 12A a 12G illustrent plusieurs variantes de 
realisation de realisation d'architectures de systemes permettant le 
chargement d'une "applet" dans une carte a puce selon I'invention. 
25 Dans ce qui suit, sans en limiter en quoi que ce soit la portee, on se 

placera ci-apres dans le cadre de ('application preferee de I'invention, sauf 
mention contraire, c'est-a-dire dans le cas d'un terminal connecte a un ou 
plusieurs serveurs eloignes via le reseau Internet. 

Avant de decrire le procede d'activation duplications localisees 
30 dans une carte a puce selon I'invention et de detainer une architecture pour 
sa mise en ceuvre, par reference a la figure 2, il apparait tout d'abord utile de 
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rappeler brievement los caracteristiques principales des protocoles de 
communication sur les reseaux. 

^architecture des reseaux de communication est decrite par 
diverses couches. A titre d'exemple, le standard "OSI" ("Open System 
5 Interconnection") , defini par I' "ISO", comporte sept couches qui vont des 
couches dites basses (par exemple la couche dite "physique" qui concerne 
le support de transmission physique) aux couches dites hautes (par exemple 
la couche dite "d'application"), en passant par des couches intermediates, 
notamment la couche dite de "transport". Une couche donnee offre ses 

w services a la couche qui lui est immediatement superieure et requiert de la 
couche qui lui immediatement inferieure d'autres services, via des interfaces 
appropriees. Les couches communiquent a I'aide de primitives. Elles 
peuvent egalement communiquer avec des couches de meme niveau. Dans 
certaines architectures, plusieurs couches peuvent etre inexistantes. 

15 Dans un environnement de type Internet, les couches sont au 

nombre de cinq, et de fa?on plus precise, en allant de la couche superieure 
a la couche inferieure : la couche dite d'application ("http", "ftp", "e-mail", 
etc.), la couche dite de transport ("TCP"), la couche dite d'adressage de 
reseau ("IP"), la couche dite de liens de donnees ("PPP", "Slip", etc.) et la 

20 couche dite physique. 

Si on se reporte de nouveau a la figure 2, a Texception de couches 
logicielles de protocole de communication specifiques, referencees 13 et 
23a, respect ivement implantees dans le terminal 1 et la carte a puce 2a, les 
autres elements, materiels ou logiciels, sont communs a Tart connu, et il n'y 

25 a pas lieu de les re-decrire de fagon detaillee. 

Le terminal 1 comprend des circuits 11 d'acces au reseau Rl y 
constitues par exemple d'un modem. Ces circuits regroupent les couches 
logicielles inferieures, Ci et C2, qui correspondent aux couches "physique" 
et de "lien de donnees". 
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On a egalement represents les couches superieures, C3 et C4, qui 
correspondent aux couches "d'adressage de reseau" ("IP", dans le cas 
d'lnternet) et de "transport" ("TCP"). La couche superieure ^application 
("http", "ftp", "e-mail", etc.) n'a pas ete representee. 
5 ^interface entre les couches inferieures, C1 et C2, et les couches 

superieures, C3 et C4, est constitute par une couche logicielle 
generalement appelee "driver couches basses". Les couches superieures, 
C3 et C4, s'appuient sur cette interface et sont mises en ceuvre par 
I'intermediaire de bibliotheques de fonctions specifiques ou bibliotheques 
10 reseau 14, avec lesquelles elles correspondent. Dans le cas du reseau 
Internet, "TCP/IP" est mis en oeuvre au moyen de bibliotheques dites de 
"sockets". 

Cette organisation permet a un navigateur 1 0 de poser des requetes 
vers un serveur 4, pour la consultation de pages "WEB" (protocole "HTTP"), 

15 pour le transfert de fichiers (protocole "FTP") ou renvoi de courrier 
electronique (protocole "e-mail"), ce de fagon tout a fait classique en soi. 

Le terminal 1 comprend egalement un lecteur de carte 3, integre ou 
non. Pour communiquer avec la carte a puce 2a, le lecteur de carte 30 
englobe egalement deux couches basses, CC1 (couche physique) et CC2 

20 (couche de lien de donnees), jouant un role similaire aux couches C1 et C2. 
Les interfaces logicielles avec les couches CC1 et CC2 sont decrites, par 
exemple, par la specification "PC/SC" ("part 6, service provider"). Les 
couches elles-memes, CC1 et CC2, sont notamment decrites par les normes 
ISO 7816-1 a 7816-4, comme il a ete rappele. 

25 Une couche logicielle supplemental 16 forme interface entre les 

couches applicatives (non representees) et les couches inferieures, CC1 et 
CC2. La fonction principale devolue a cette couche 16 est une fonction de 
multiplexage/demultiplexage. 

Les communications avec la carte a puce 2a s'effectuent selon un 

30 paradigme similaire a celui utilise pour la manipulation de fichiers dans un 
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systeme Sexploitation du type "UNIX" (marque deposee) : OUVRIR 
("OPEN"), LIRE ("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), etc. 

Du cote de la carte a puce 2a, on retrouve une organisation 
similaire, a savoir la presence de deux couches basses, referencees CCai 
5 (couche physique) et CCa2 (couche de lien de donnees), ainsi qu'une 
couche d'interface 26a, tout a fait similaire a la couche 16. 

Selon une premiere caracteristique de ['invention, on prevoit, de part 
et d'autre, c'est-a-dire dans le terminal 1 et dans la carte a puce 2a, deux 
couches de protocoles specif iques : 13 et 23a, respectivement. 
10 Dans le terminal 1, la couche specif ique 13 s'interface aux "drivers 

couches basses" 15, aux bibliotheques 14 des couches reseau, C3 et C4, et 
aux couches protocolaires du lecteur de carte 3, c'est-a-dire les couches 
inferieures, CC1 et CC2, via la couche de multiplexage 16. La couche 
specif ique 13 permet le transfer! de paquets reseaux de et vers la carte a 
15 puce 2a. En outre, elle adapte les applications existantes telles le navigateur 
Internet 10, le courrier electronique, etc., pour des utilisations mettant en 
oeuvre la carte a puce 2a. 

Du cote de la carte a puce 2a, on retrouve une organisation tout a 
fait similaire constitute- par une instance supplemental de la couche 
20 specifique, referencee 23a, pendant de la couche 13. 

De fagon plus precise, les couches specif iques, 13 et 23a, sont 
subdivisees en trois elements logiciels principaux : 

un module, 130 ou 230a, de transfert de blocs d'informations 
entre les couches 13 et 23a, via les couches conventionnelles CC1, CC2, 
25 CCai et CCa2 ; 

une ou plusieurs pieces de logiciel, dites "agents intelligents", 
132 ou 232a, qui realisent, par exemple, des fonctions de conversion de 
protocoles ; 
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et un module de gestion de la configuration specifique, 131 et 
231a, respectivement ; module qui peut etre assimile a un agent intelligent 
particulier. 

Pour simplifier, on appellera ci-apres les agents intelligents, 
5 "agents", comme il a ete precedemment indique. 

On retrouve done, dans le terminal 1 et la carte a puce 2a, une pile 
protocolaire de communication entre les deux entites. 

Les couches de niveau deux (couches de lien de donnees), CC2 et 
CCa2, assurent I'echange entre la carte a. puce 2a et le terminal 1 . Ces 
10 couches sont responsables de la detection et I'eventuelle correction 
d'erreurs de transmission. Differents protocoles sont utilisables, et a titre 
d'exemples non exhaustifs les suivants : 

la recommandation ETSI GSM 11.11 ; 

le protocole defini par la norme ISO 7816-3, en mode caractere 

15 1=0 ; 

le protocole defini par la norme ISO 7816-3, en mode bloc T=1 

ou le protocole defini par la norme ISO 3309, en mode trame 
"HDLC" (pour "High-Level Data Link Control procedure" ou procedure de 
20 commande de liaison a haut niveau). 

Dans le cadre de I'invention, on utilisera de preference le protocole 
ISO 7816-3, en mode bloc. 

De facon connue en soi, a chaque couche de protocole, il est 
associe un certain nombre de primitives qui permettent les echanges de 
25 donnees entre couches de meme niveau et d'une couche a I'autre. A titre 
d'exemple, les primitives associees a la couche de niveau deux sont du type 
"demande de donnees" ("Data.request") et "envoi de donnees" par la carte 
("Data.response"), ainsi que "confirmation de donnees" {"Data.confirm"), etc. 
De facon plus specifique, les couches 13 et 23a sont chargees du 
30 dialogue entre la carte a puce 2a et I'hote, e'est-a-dire le terminal 1. Ces 
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couches permettent lechange d'informations entre un utilisateur (non 
represente) du terminal 1 et la carte a puce 2a, par exemple via des menus 
deroulants sous la forme d'hypertexte au format "HTML". Elles permettent 
aussi la mise en place d'une configuration adaptee pour remission et/ou la 
5 reception de paquets de donnees. 

Comme il a ete indique ci-dessus, les couches comprennent trois 
entites distinctes. 

La premiere couche, 130 ou 230a, est essentiellement constitute 
par un multiplexeur logiciel. Elle permet I'echange d'informations entre la 
w carte a puce 2a et le terminal hote 1 , sous la forme d'unites de donnees de 
protocole. Elle joue un role similaire a celui d'un commutateur de paquets de 
donnees. Ces unites sont emises ou regues via la couche de niveau deux 
(couche de liens de donnees). Ce protocole particulier de communication 
permet de mettre en communications au moins une paire d' "agents". Le 
15 premier agent de chaque paire, 132, est situe dans la couche 13, cote 
terminal 1 , le second, 232a, est situe dans la couche 23a, cote carte a puce 
2a. Une liaison entre deux "agents" est associee a une session, que Ton 
pourra appeler "S-Agent". Une session est un echange de donnees 
bidirectionnel entre ces deux agents. Si I'une ou I'autre des couches, 13 et 
20 23a, comporte plusieurs agents, les agents d'une meme couche peuvent 
aussi etablir de sessions entre eux et/ou avec les modules 131 et 231a, qui 
constituent des agents particuliers. 

De fagon plus precise, un agent est une entite logicielle autonome 
qui peut realiser tout ou partie de fonctions des couches de niveau trois et 
25 quatre, en fonction de la configuration mise en oeuvre par le terminal 1 . 

Les agents sont associes a des proprietes ou attributs particuliers. 
Pour fixer les idees, et a titre d'exemple non limitatif, les six proprietes 
suivantes sont associees aux agents : 

"hote" : agent localise dans le terminal ; 
30 - "carte" : agent localise dans la carte a puce ; 

"local" : agent ne communiquant pas avec le reseau ; 
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"reseau" : agent communiquant avec le reseau (cote terminal) ; 
"client" : agent qui initialise une session ; 
"serveur" : agent qui regoit une demande de session. 
Un agent particulier est identifie par une reference, par exemple un 
5 nombre entier de 16 bits (c'est-a-dire compris entre 0 et 65535). Le bit de 
poids fort (b15 = 1) indique si la reference est locale (communications 
locales a la carte a puce ou au terminal) ou distante (b15 = 0). 

II existe deux grandes categories d'agents : les agents de type 
"serveur", qui sont identifies par une reference fixe, et les agents de type 
10 "client", qui sont identifies par une reference variable, que Ton peut qualifier 
d'ephemere, delivree par le module de gestion de configuration, 131 ou 
231a. 

Les agents communiquent entre eux a I'aide d'entite dites "unites de 
donnee de protocole" ou "pdu" (pour "protocol data unit", selon la 
15 terminologie anglo-saxonne) constituant une reference de destination et une 
reference de source. On pourrait egalement appeler cette "pdu" particuliere 
"SmartTP pdu", en reference au terme anglais "Smart Card" (carte a puce) 
couramment utilise. Les "pdu" utilisent notamment les references definies ci- 
dessus. 

20 Une "SmartTP pdu", ou plus simplement "pdu" ci-apres, comporte 

une reference source, une reference de destination, un ensemble de bits 
constituant des drapeaux ou "flags" qui precisent la nature de la "pdu", et 
des donnees optionnelles : 

- le drapeau "OPEN" (ouvert) est positionne pour indiquer I'ouverture 
25 d'une session ; 

- le drapeau "CLOSE" (ferme) indique la fermeture d'une session ; et 

- Le drapeau "BLOCK 11 (verrouille) indique que Tagent est en attente d'une 
reponse de son correspondant et suspend toute activite. 

On appellera jeton une "pdu" qui ne comporte pas de donnees. 
30 Uentite "SmartTP" controle 1'existence de Tagent destinataire et 

realise la commutation d'un paquet vers ce dernier. 
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Une session agent "S-Agent n possede trois etats remarquables, a 

savoir : 

- un etat deconnecte : aucune session n'est ouverte avec un autre agent 

- un etat connecte : une session est ouverte avec un autre agent, une 
5 session n S-Agent" etant identifiee par une paire de references ; et 

- un etat bloque, I'agent etant connecte et attendant une reponse de son 
correspondant. 

Le mecanisme d'etablissement d'une session "S-Agent" est le 

suivant : 

10 - une nouvelie instance d'un agent client est creee (cote carte a puce ou 
terminal), cet agent etant identifie par une reference ephemere pseudo- 
unique ; 

- i'agent client emet une "pdu" a destination d'un agent serveur (dont la 
reference est connue par ailleurs) avec le drapeau "OPEN" positionne et 

15 I'agent client passe a I'etat connecte ou bloque selon la valeur du drapeau 
"BLOCK 1 ; et 

- I'agent serveur regoit la "pdu" avec le drapeau "OPEN" et passe a I'etat 
connecte 

Une fois une session ouverte, deux agents echangent des donnees 
20 via des "pdu". 

Le mecanisme de fermeture d'une session est le suivant : 

- un agent emet une "pdu" avec le drapeau "CLOSE" positionne (et 
qui comporte eventuellement des donnees ; et 

- Tautre agent regoit une "pdu" avec le drapeau "CLOSE 1 positionne 
25 (et qui comporte eventuellement des donnees) et la session "S-Agent" passe 

a I'etat deconnecte. 

La figure 3 illustre de fagon schematique le diagramme d'etats des 
sessions "S-Agent" , telles qu'elles viennent d'etre rappelees. 

Les couches 130 et 230a gerent des tables (non representees) qui 
30 contiennent la liste des agents presents, cot6 terminal hote 1 et carte a 
puce 2a. 
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De fagon pratique, les agents permettent d'echanger des donnees 
(de I'hypertexte, par exemple), mais egalement de declencher des 
transactions reseau, autorisant des communications entre la carte a puce 2a 
et un serveur Sloigne 4 (figure 2). 
5 Les modules de gestion de configuration, 131 et231a, 

respectivement, sont assimilables a des agents particuliers. Par exemple, le 
module 131 , cote terminal hote 1 , gere notamment des informations relatives 
a la configuration de ce terminal (modes de fonctionnement), liste des autres 
agents presents, etc. Le module 231a, cote carte a puce 2a, a des fonctions 

w analogues. Ces deux agents peuvent etre mis en communication Tun avec 
I'autre pour etablir une session. 

De fagon pratique, la carte a puce 2a est avantageusement 
"adressee" par utilisation d'une adresse "URL" (pour "Universal Resource 
Locator") definissant un rebouclage sur le terminal 1 lui-meme, et non un 

15 pointage sur un serveur externe. A titre d'exemple, la structure de cette 
"URL" est habituellement la suivante : 

http://1 27.0.0.1:8080 (1), 
dans laquelle 127.0.0.1 est I'adresse "IP" de rebouclage et 8080 est le 
numero de port. 

20 La figure 4 illustre de fagon simplifiee I'architecture logique d'un 

systeme selon I'invention du type represents sur la figure 2, mais represents 
de fagon plus detaillee. La carte a puce 2a comprend plusieurs agents, dont 
deux seulement ont ete represents : un agent de type non precisement 
defini 232ai et un agent 232a2, de type dit "WEB". La pile logique 

25 comprend, les couches de protocoie inferieures, referencees 200a, 
repondant aux normes ISO 7816-3 (figure 2 : CCai et CCa2), le gestionnaire 
de commandes "APDU" 201ai, et le multiplexer de paquets 230a, ce 
dernier etant interface aux agents, notamment I'agent "WEB" 231 a2. 

Du cote terminal, il existe deux piles, Tune communiquant avec le 

30 reseau Internet ff/, I'autre avec la carte a puce 2a. La premiere pile 
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comprend les organes 1 1 (figure 2 : Ci et C2) d'acces au reseau (normes 
OS! 1 et 2) et les couches de protocole "TCP/IP" (figure 2 : C3 et C4), 
referencees 100. Ces dernieres couches sont interfacees avec le navigateur 
"WEB" 10. L'autre pile comprend les couches de protocole inferieures, 
5 referencees 101, repondant aux normes ISO 7816-3 (figure 2 : C1 et C2)> le 
gestionnaire 102 d'ordres "APDU" et le multiplexeur de paquets 130, ce 
dernier etant interface avec des agents, dont un seul 132, est represents. Ce 
dernier, que Ton supposera de "type reseau", peut en outre communiquer, 
d'une part avec le navigateur 10, via les couches 'TCP/IP" 101, d'autre part 

10 avec le reseau Internet Rl, via ces memes couches "TCP/IP" 101 et I'organe 
1 1 , d'acces au reseau Rl. 

Le gestionnaire d'ordres "APDU" 201a est egalement interface avec 
une ou plusieurs couches de niveau applications, que Ton appellera 
simplement applications. Ces applications, A, A, Ai. sont » comme il a 

15 ete indique, des applications de type conventionnel. 

En resume, la fonction client/serveur "WEB", fournie par la carte a 
puce 2a, peut etre realisee par Passociation de I'agent "WEB" 232ai dans la 
carte a puce et de I'agent reseau 132 dans le terminal 1, et par la mise en 
oeuvre de sessions entre agents, comme il a ete decrit. 

20 La carte a puce 2a presente done bien la fonctionnalite 

client/serveur "WEB". En outre, selon une caracteristique du procede de 
Pinvention, n'importe quelle application conventionnelle, >4i a A n , du type 
"CGA" precite, peut etre activee au travers de ce client/serveur "WEB", soit 
par le navigateur "WEB" 10 present dans le terminal 1 , soit par un navigateur 

25 eloigne 4, localise en un point quelconque du reseau Internet Rl t par la mise 
en oeuvre de sessions entre agents. Selon le procede de I'invention, les 
applications, A\ a A n , ne necessitent pas d'etre re-ecrites et sont mises en 
oeuvre telles quelles. 

Dans le cadre de I'invention, tout ou partie des applications A-\ a A n 

30 peut etre constitute par des "applets", chargees initialement dans une 
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memoire non volatile de la carte a puce 2 ou, au contraire, chargees par 
I'intermediaire des deux programmes de chargement OL et IL, dont on 
precisera ci-apres la nature et les lieux de stockage possible. 

Selon un autre aspect de I'invention, la fonction serveur "WEB" 
5 offerte par la carte a puce inclut un mecanisme similaire a la fonction dite 
M CGI M (pour "Common Gateway Interface" ou "interface de passerelle") 
implantee dans les serveurs "WEB" classique. 

Avant de decrire un exemple d'architecture conforme a I'invention, 
permettant de realiser une fonction de ce type, au sein meme de la carte a 
w puce, il est utile de rappeler les principales caracteristiques d'un mode de 
fonctionnement "CGI". 

Le "CGI" est une specification de mise en ceuvre, depuis un serveur 
"WEB", duplications ecrites pour les systemes d'exploitation "UNIX" 
(marque deposee), "DOS", ou "WINDOWS" (marque deposee). A titre 
15 d'exemple, pour le systeme d'exploitation "UNIX", la specification est 
"CGI 1.1" et pour le systeme d'exploitation "WINDOWS 95", la specification 
est "CGI 1.3". 

Toujours a titre d'exemple, une requete "HTTP" pour une adresse 
"URL", du type : 

20 "http://www.host.com/cgi~bin/xxx.cgi" (2), 

dans laquelle "host" se refere a un systeme hote (generalement eloigne), 
est interpretee par un serveur "WEB" comme I'execution d'un script de 
commande, de type "CGI" nomme "xxx" et present dans le repertoire "cgi- 
bin" de ce systeme hote. Bien que le nom du repertoire puisse etre a priori 

25 quelconque, par convention, c'est le nom donne au repertoire stockant les 
scripts de type "CGI". Un script est une suite destructions du systeme 
d'exploitation du systeme hote dont le resultat final est transmis au 
navigateur "WEB" emetteur de la requete precitee. Differents langages 
peuvent etre utilises pour ecrire ce script, par exemple le langage "PERL" 

30 (marque deposee). 
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De fagon pratique, la requete est habituellement affichee sur un 
ecran informatique sous la forme d'un formulaire compris dans une page 
"HTLM". Le langage "HTLM" permet de traduire un formulaire en une 
adresse "URL". Le formulaire comporte un ou plusieurs champs, obligatoires 
5 ou non, qui sont remplis par un utilisateur a Paide des moyens de saisie 
habituels : clavier pour le texte, souris pour les cases a cocher ou les 
boutons dits "radio", etc. Le contenu du formulaire (ainsi qu'eventuellement 
des informations et instructions dites "cachees") est emis a destination du 
serveur "WEB". Le code "HTLM" de la page decrit la structure materielle du 
10 formulaire (cadre, graphisme, couleur, et tout autre attribut), ainsi que la 
structure des champs de donnees a saisir (nom, longueur, type de donnees, 
etc.). 

La transmission peut s'effectuer selon deux types de formats 
principaux. Un premier format utilise la methode dite "POST" et un second la 
15 methode dite "GET". Une information de type de format est presente dans le 
code de la page formulaire. 

Ce mecanisme n'est cependant pas directement transposable a une 
carte a puce, meme si celle-ci offre la fonctionnalite client/serveur "WEB" 
conformement a Tune des caracteristiques de Pinvention. 
20 On va maintenant decrire un exemple d f architecture permettant 

d'activer une application quelconque, de type conventionnel, via un serveur 
"WEB" sur la carte a puce, par reference a la figure 5. 

Parmi les agents intelligents, conforme a Tun des aspects de 
Pinvention, on prevoit des agents intelligents particuiiers, que Pon appellera 
25 ci-apres "Agents traducteurs de script" ou de fagon abregee "ATS". Le script 
est alors interprets par un des agents intelligents. Cette traduction peut etre 
realisee de differentes manieres : 

a/ par Pagent "WEB" 232ai lui-meme, qui est dote dans ce cas d'une 
double capacite ; 
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b/ par un agent script unique capable de traduire Pensemble des scripts 
presents dans la carte a puce 2a ; 

c/ par un agent de script dedie que Ton appellera "ATSD" ci-apres (un 
agent par script) ; ou 
5 61 par un agent "APDU" 2010a du gestionnaire d'ordres "APDU" 201a, 
qui est dote, dans ce cas, d'une double capacite. 

L'agent "APDU" 2010a est une composante de la couche 
gestionnaire d'ordres "APDU" 201a. Cette derniere est une couche capable 
de centraliser tous les ordres "APDU" emis et/ou regus par le systeme, de 
w selectionner des applications, parmi >4 1 a A n , mais egalement d'offrir une 
interface de type agent intelligent. Elle est done capable, selon Tune des 
caracteristiques de 1'invention de communiquer avec tous les agents 
intelligents (via des sessions), que ces agents soient localises dans 
Tenceinte 6 ou la carte a puce 2a. 
15 Dans le cas c/ ci-dessus, une session est ouverte entre I'agent 

"WEB" 232ai et run des agents "ATSD". 

La figure 5 illustre un exemple d'architecture pour laquelle les 
agents traducteurs sont du type "ATSD". lis sont references ATS, a ATS n et 
associes aux applications A^ a A n , L'application selectionnee etant supposee 
20 etre l'application A, la session s'etablit entre I'agent "WEB" 232ai et I'agent 
ATS.. 

Un agent traducteur de script genere une suite d'ordres "APDU". 
Une session est ouverte entre I'agent traducteur, par exemple I'agent ATS., 
et I'agent "APDU" 2101a. Les ordres sont alors emis vers I'agent 
25 "APDU" 2101a. Le gestionnaire d'ordres "APDU" 210a selectionne 
l'application "CGA" A. et lui transmet les ordres "APDU", ordres traduits et 
done conventionnels, qu'elle est en mesure de comprendre. Cette 
application est done correctement activee, sans avoir a la modifier ou a la 
reecrire. 
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Les reponses de I'application A. sont transmises au gestionnaire 
d'ordres "APDU" 210a, a I'agent "APDU" 2010a, puis de nouveau a I'agent 
ATS. (et de fagon plus generate a I'agent traducteur de script). 

Les differents cheminements sont represents symboliquement sur 
5 la figure 5 par des traits pleins reliant les blocs fonctionnels, ou en pointilles 
a I'interieur de ces blocs. 

Le procede selon I'invention utilise les deux caracteristiques qui 
viennent d'etre rappelees : fonctionnement de la carte a puce en tant que 
serveur/client "WEB", inciuant une fonction "cgi". Le chargement d'une 
to "applet" dans la carte a puce s'effectue en etfet via I'interface "CGI" offerte 
par celle-ci. 

De fagon plus precise, selon une caracteristique de I'invention, la 
partie de programme de chargement IL, localisee dans la carte a puce 2a, 
est constitute par un script. II s'agit, par exemple, d'un script associe a 

15 ('application referencee A. sur la figure 5. Ce script est, selon une 
caracteristique du procede de ['invention, active par une requete "HTTP", les 
echanges entre la partie OL et la partie IL s'effectuant selon le protocole de 
communication "TCP/IP". Les programmes IL et OL deviennent de ce fait a 
priori compatibles. En outre, il n'est plus necessaire que la proximite 

20 physique soit respectee, comme dans Cart connu (voir figure 1). La partie OL 
peut desormais etre localisee dans le terminal ou, de preference, dans un 
serveur eloigne (les liaisons entre le serveur et le terminal s'effectuant 
suivant le protocole "TCP/IP"), voire, comme il le sera montre, etre stockee 
dans la carte a puce elle-meme. La requete "HTTP" precitee est initiee par la 

25 partie OL. 

II convient de remarquer que les donnees adressees a I'agent 
"WEB" 232ai sont transportees, de fagon conventionnelle en soi, sous 
formes d'ordres "APDU" destines a Tapplication particuliere constitute par le 
"Multiplexer de paquets" 230a. Le gestionnaire d'ordres "APDU" 201a 
30 selectionne cette application de maniere tout a fait similaire aux autres 
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applications de type "CGA", A<\ a A n , presentes dans la carte a puce 2a. En 
d'autres termes, le multiplexeur de paquets 230a est vu par le gestionnaire 
d'ordres "APDU" 201a comme une application "CGA" ordinaire. 

La requete "HTTP" est analysee par I'agent "WEB" 232ai qui 
5 detecte une reference a un repertoire particulier, que I'on appellera ci-apres 
par convention "cgi-smart" (par analogie a "cgi-bin"), d'une part, et a une 
application particuliere, IL dans le cas de I'exemple decrit. Le chemin 
complet est done, en I'occurrence "cgi-smart/il". 

Selon une caracteristique du procede de ('invention, I'entite M il M ci- 
10 dessus designe un script particulier associe une application egalement 
particuliere (IL en I'occurrence). 

Une session est ouverte entre I'agent traducteur, par exemple 
I'agent ATS U et I'agent "APDU" 2010a. L'agent traducteur de script ATS\ 
genere une suite d'ordres "APDU". Les ordres sont emis vers I'agent 
15 "APDLT 2010a. Le gestionnaire d'ordres "APDU" 201a selectionne 
('application "CGA" Aj (par exemple ('application IL) et lui transmet les ordres 
"APDU", ordres traduits et done conventionnels, qu'elle est en mesure de 
comprendre. Cette application est done correctement activee. 

La reponse de I'application IL (Aj) est transmise en sens inverse au 
20 gestionnaire d'ordres "APDU" 201a, a I'agent "APDU" 2010a, puis de 
nouveau a I'agent ATSj (et de fagon plus generale a I'agent traducteur de 
script). 

La reponse, constitute par un formulaire en langage "HTLM" 
reprend le chemin inverse, par la mise en oeuvre de sessions entre agents 
25 intelligents apparies, pour etre re-transmise au terminal 1 et, eventuellement 
a un serveur eloigne 4 (figure 4), via le reseau Internet Rl, pour atteindre 
finalement I'application OL. 

La figure 6 illustre schematiquement ('architecture logique 
permettant le chargement d'une "applet" selon le procede de invention. On 
30 retrouve sur ce schema les blocs materiels constitues par le terminal 1 , le 
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lecteur de carte a puce 3 et la carte a puce 2a, communiquant par mise en 
oeuvre du protocole normalise ISO 7816 precite et Pechange d'ordres 
"APDU", de maniere classique en sol La partie OL est mise en relation avec 
la partie IL (sous forme d'un script reference ILs), par des echanges selon le 
5 protocole Internet "TCP/IP", de la maniere decrite precedemment, par mise 
en oeuvre des fonctions serveur "HTTP" (reference SC) et "CGI" de la carte a 
puce 2a. 

On doit bien comprendre que, bien que represents a Pexterieur de 
la carte a puce 2a pour des raisons de commodite, les blocs SC et ILs sont 
10 constitues par differents modules internes de celle-ci, qui ont ete decrits par 
reference a la figure 5. 

Par contre, le programme OL n'est pas obligatoirement stocke dans 
le terminal 1 . 

On va maintenant detainer un premier exemple de chargement 
15 d'une "applet" dans une carte a puce 2a, par mise en oeuvre de la methode 
dite "GET". 

On suppose que le fichier de chargement de P "applet", reference 7, 
presente la structure illustree par la figure 7 : une entete 70, un corps 
principal 71 constitue par du "Byte Code" en langage "JAVA" et une 
20 signature electronique 72. L'entete represente un identifiant d'une application 
particuliere, generalement appele "Application Identifier" ou simplement 
"AID". La signature electronique 72 est un mot chiffre avec une cle publique 
ou privee, obtenu a partir du code 71 . L'ensemble du fichier 7 peut 
egalement etre chiffre, pour des raisons de confidentialite, lorsqu'il s'agit 
25 d f applications dites sensibles. Optionnellement, on peut prevoir une ou 
plusieurs signature(s) electronique(s) supplementaire(s) non representee(s). 

Les principales etapes du processus sont illustrees 
schematiquement par la figure 8. 

Pendant une premiere etape, la partie de programme de 
30 chargement OL recupere, par une commande de type "GET", un formulaire 
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de chargement a partir de la carte a puce 2a, formulaire en langage "HTML" 
que Ton appellera arbitrairement "download.html". 

Cette recuperation est effectuee en consultant une page 
correspondante dont TURL est typiquement de la forme suivante : 
5 http://1 27.0.0. 1:8080/download.html (3), 

dans laquelle http://1 27.0.0. 1:8080 est I'adresse URL de rebouclage 
proprement dite, telle qu'elle a ete definie par la relation (1), et 
"download.html" la page "HTML" a obtenir. Cette requete met en oeuvre une 
session entre agents intelligents comme il a ete decrit en regard des figures 

10 2 a 4, selon un premier aspect de I'invention. La carte a puce 2a joue alors le 
role d'un serveur "WEB". 

La carte a puce 2a envoie le formulaire "download.html" lors d'une 
deuxieme etape, toujours par ouvertures de sessions entre agents 
intelligents apparies, selon le procede de I'invention. Le formulaire obtenu 

15 peut etre affiche sur un ecran 5 par I'intermediaire du navigateur 10. 

Pour fixer les idees, un exemple d'un tel formulaire 8 est illustre par 
la figure 9. Outre diverses zones graphiques et de textes 80 (titre, etc.), le 
formulaire comprend des zones d'affichage pour I'entete 70 du fichier de 
chargement 7, le "Byte Code" 71 et la signature 72. La zone d'affichage 71 

20 est du type dit "TEXTAREA" en langage "HTML" et presente une facilite dite 
d' "ascenseur" pour I'affichage deroulant de textes longs. Les informations 
correspondantes, telles qu'elles apparaissent sur la figure 9, sont purement 
arbitraires. Enfin, on prevoit, de fagon classique en soi, un bouton d'envoi 
"send", reference 81 , et un bouton de remise a zero "reset", reference 82. 

25 Ces boutons sont a la disposition d'un utilisateur du terminal (non 
represente). Le bouton d'envoi 81 permet de valider le formulaire et le 
retransmet a la carte a puce 2a ("soumettre le fichier de chargement" sur la 
figure 8) et le bouton de remise a zero 82 permet d'effacer les informations 
affichees et de re-initialiser le formulaire. 

30 Le code "HTML" necessaire pour programmer un tel formulaire est 

bien connu en soi et est a la portee de I'homme de metier. II n'est pas 
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necessaire de le detaillor de nouveau. On peut cependant indiquer qu'il 
contient notamment une ligne de code en langage "HTML" qui se presente 
typiquement sous la forme : 

<form action="http.7/1 27.0.01 :8080/cgi-smart/loader"> (4), 
5 dans laquelle http://1 27.0.01:8080 est I'URL de rebouclage de la relation (1), 
cgi-smart le repertoire "CGI" precite contenant le script de chargement 
"loader" que Ton a appele "il", script associe a la partie IL du programme de 
chargement. 

Si I'affichage visuel du formulaire 8 sur I'ecran 5 n'est pas souhaite 
w (par exemple s'il n'y a pas d'operateur humain, les informations peuvent etre 
cachees incorporant le parametre "HTML" suivant : "TYPE=hidden" dans la 
ligne de code (4) precitee. 

Lors d'une troisieme etape, la partie OL envoie une requete "HTTP" 
de type "GET" a la carte a puce 2a, toujours par ouverture de sessions entre 
15 des agents intelligents apparies. En faisant appel a la fonction "CGI" offerte 
par la carte a puce 2a, telle qu'elle a ete decrite en regard de la figure 5, 
I'application IL s'execute, le serveur "WEB" forme par la carte a puce 2a 
passant les parametres de la requete "HTTP" a cette derniere application. 

La requete precitee contient une ligne de code typiquement de la 
20 forme suivante : 

Smart/loader?AID=xxx&ByteCode=yyy&Signature=zzz (5), 
Dans laquelle "xxx" est I'entete 70 ("2001" dans I'exemple de la 
figure 9), "yyy" est le "Byte Code" 71 ("0123456789ABCDEF" dans I'exemple 
de la figure 9) et "zzz" la signature electronique 71 ("0123456789ABCDEF" 
25 dans I'exemple de la figure 9). Les trois parties du fichier de chargement sont 
done bien inserees dans trois champs du formulaire "HTML" 8, sous forme 
concatenee. 

Le chargement d'une "applet" particuliere identifiee par I'entete 70 a 
lieu a ce moment. 

30 Enfin, lors d'une quatrieme etape un code de retour est transmis de 

la partie IL a la partie OL, toujours par mise en oeuvre de sessions entre 
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agents apparies. II s'agit en general d'un simple acquittement ou, si 
I'operation ne s'est pas realisee correctement d'un code d'erreur. Dans ce 
dernier cas, il est necessaire de renouveler les etapes 1 a 4. 

Comme solution alternative, il est possible d'utiliser la methode 

5 "POST" precitee. Pour fixer les idees, la figure 1 0 illustre un exemple d'un tel 
formulaire reference 8'. On retrouve diverses zones de texte et de graphique 
80, une zone d'affichage de I'entete 70 et une zone d'affichage de la 
signature electronique 72, ainsi que des boutons d'envoi "send" 81 et de 
remise a zero "Reset" 82. Ces elements jouent un role tout a fait similaire 

w aux elements de memes reference de la figure 9 et il est inutile de les re- 
decrire. Par contre, la zone d'affichage 71' ne visualise plus explicitement le 
"Byte Code", mais un repertoire ou un sous-repertoire ou le code de I' 
"applet" a charger est enregistre. En I'occurrence, cette zone pointe sur un 
fichier, appele arbitrairement "APPLET.BIN", enregistre sur une unite de 

15 stockage appelee "C", qui peut etre un disque dur present dans le terminal 1 . 
Un bouton supplemental de navigation "browse" 83 permet de balayer les 
divers (sous-)repertoires de ce disque et de selectionner un fichier particulier 
("APPLET.BIN"). 

La methode "POST" comme la methode "GET" est bien connue en 
20 soi, et il est inutile de la re-decrire en detail. Dans le cadre precis de 
('invention, I* "applet" correspondant au fichier "APPLET.BIN" est chargee, a 
partir de I'unite "C", de maniere similaire a ce qui a ete decrit pour la 
methode "GET". 

On va maintenant decrire un deuxieme exemple de chargement 
25 d' "applet" dans la carte a puce 2a. 

II est egalement possible d'enchamer plusieurs formulaires lors du 
chargement. A la place d'un simple statut (acquittement ou code d'erreur 
dans le premier exemple decrite en regard de la figure 8), le retour de la 
partie IL contient alors un nouveau formulaire. Ainsi, des sequences 
30 dynamiques d'echanges entre les parties OL et IL peuvent etre realisees. 
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Par exemple, apres analyse du fichier de chargement, la partie IL 
peut demander une autorisation (c'est-a-dire une signature electronique) 
supplementaire, par exemple celle d'une instance gouvernementale. Elle 
renvoie alors a la OL un formuiaire qui peut avoir typiquement la structure 
5 "HTML" suivante (6) : 



10 



<TITLE>Authorisation form </TITLE> 

<FORM ACTION="http://@carte:8080/cgi-smart/loader"> 

<INPUT TYPE="text" NAME="GouvSignature" MAXLENGTH="8">Signature 

</FORM> 



dans laquelle "Authorisation form", entre les balises "HTLM" denommees 
"<TITLE>" et </TITLE>, represente le titre (arbitraire) du formuiaire, "@carte" 
la traduction litterale de I'adresse URL de rebouclage de la relation (1) et 
15 8080 le numero de port, la ligne de code : 

<INPUT TYPE="text" NAME="GouvSignature" MAXLENTH="8">Signature 
(7) 

requiert Tentree d'une variable appelee arbitrairement "Signature", en mode 

texte, de longueur maximale 8 octets, et </FORM> est la balise "HTML" 
20 indiquant la fin du code de formuiaire. 

Le processus complet comprend alors deux etapes supplementaires 

avant I'etape finale d'acquittement ou de code d'erreur, soit six etapes, 

comme illustre par la figure 1 1 . 

De fagon plus generate, le nombre d'allers et retours peut dependre 
25 de parametres figurant dans Tun ou ('autre des formulaires echanges entre la 

carte a puce et la partie OL des programmes de chargement. 

Jusqu'a ce point, la localisation de la partie OL n'a pas ete precisee 

expressement. Outre le fait que le procede rend, a priori, compatible OL et 

IL, il permet aussi une tres grande souplesse precisement quant a cette 
30 localisation, etant entendu que la partie IL est stockee dans la carte a puce 

2a comme formant Tune des applications presente dans cette carte a puce. 

Le procede selon I'invention presente notamment I'avantage supplementaire 
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de ne plus exiger une proximite physique entre les deux parties OL et IL, 
puisqu'elles ne sont plus tributaires du protocole de communication ISO 
7816, les echanges entre ces deux portions de logiciel mettant en ceuvre le 
protocole de communication Internet TCP/IP. 
5 Aussi, la partie OL, ainsi que les donnees proprement dites de 

r "applet" a charger sur la carte a puce 2a peuvent etre stockees soit en 
local, soit dans un site eloigne. Dans tous les cas cependant, les echanges 
entre ces deux parties mettent en oeuvre, comme il vient d'etre rappele, un 
protocole de communication "TCP/IP" et le chargement d'une "applet" se 
w deroule comme il a ete rappele precedemment grace aux fonctions de 
serveur/client "WEB" et "CGI" offertes par la carte a puce 2a. 

On va decrire maintenant, par reference aux figures 12A a 12G, les 
principales architectures pouvant etre mises en oeuvre dans le cadre de 
['invention. 

15 La figure 12 A illustre une architecture de systeme selon laquelle la 

partie OL est stockee en local sur le terminal 1. Celui-ci est connecte a un 
serveur eloigne 4, via le reseau Internet RL Les donnees de I' "applet" a 
charger dans la carte a puce 2a, referencees Da, sont stockees sur ce 
serveur 4. Une requete "HTTP" permet de les transferer vers la carte a puce 
2a, via le terminal 1 (et un lecteur de carte a puce non represented par mise 
en ceuvre du protocole de communication Internet "TCP/IP". 

Dans I'architecture de systeme representee sur la figure 12B, la 
partie de programme de chargement OL et les donnees Da sont stockees 
localement dans le terminal 1 . La connexion du terminal 1 au reseau Internet 
Rl est optionnelle. Pour le moins, elle n'est pas requise pour le chargement 
d'une "applet" selon les etapes du procede de 1'invention. Cette connexion a 
ete representee en traits pointilles. Le terminal peut done etre autonome. 

Dans I'architecture de systeme representee sur la figure 12C, la 
partie de programme de chargement OL et les donnees Da sont stockees 
dans un serveur distant 4. Les communications entre le serveur 4 et la carte 
a puce 2a, via le reseau Internet Rl, le terminal 1 et le lecteur de carte a 
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puce (non represents) s'effectue par des requetes "HTTP", et mise en oeuvre 
du protocole "TCP/IP". 

L'architecture de systeme representee sur la figure 12D est similaire 
a celle de la figure 12C. La seule difference est que la partie de programme 
5 de chargement OL est stockee dans un premier serveur distant, reference 
4a, et que les donnees 0a, sont stockees dans un second serveur distant, 
reference 4b, 

Dans ('architecture de la figure 12E, la partie du programme de 
chargement, referencee ici OL', est constitute par un composant du 
10 navigateur 10 lui-meme. II s'agit avantageusement d'une "applet" integree 
dans ce navigateur. Le type d'entree a utiliser dans ce cas est "file" (fichier). 

De fagon avantageuse egalement, les donnees Da, de P "applet" a 
charger sur la carte a puce 2a, peuvent etre stockees sur un support 
d'enregistrement de donnees externe 9, par exemple une disquette comme 
75 illustre par la figure 12E. Naturellement d'autres supports sont utilisables : 
CedeROM, bande magnetique, etc. 

Si on utilise la methode "POST" precitee, il suffit de specifier la lettre 
de Punite de stockage, par exemple "A" pour la disquette 9, un eventuel 
chemin (repertoire, sous-repertoires) et le nom du fichier a charger. Pour 
20 fixer les idees, le chemin complet pourrait etre typiquement : 

A:\APPLET.BIN (8) 
Du fait de la fonction serveur/client "WEB" offerte par la carte a 
puce 2a, selon une des caracteristiques du procede de Pinvention, le 
navigateur 10 est a meme, contrairement a Part connu, de communiquer 
25 directement avec cette derniere, comme il Pa ete montre en regard des 
figures 2 a 4. Les communications s'effectuent par Pouverture de sessions 
entre agents apparies. 

^architecture de systeme illustree par la figure 12F est une variante 
de Parchitecture de la figure 12E. Selon cette variante, la partie de 
30 programme de chargement OL est stockee dans la carte a puce 2a elle- 
meme, sous forme d'une "applet" en langage "JAVA". Par une requete 
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"HTTP", cette "applet" peut etre chargee dynamiquement sur le terminal 1, 
en OL". Ce chargement s'effectue a I'aide de requetes posees par le 
navigateur 10, lors d'etapes preliminaires. Une fois la partie OL chargee, les 
etapes ulterieures sont communes au cas precedent. Les donnees Da 
5 peuvent egalement etre stockees sur un support externe, par exemple une 
disquette 8. 

L'architecture de systeme de la figure 12G est une variante de celle 
de la figure 12F. La seule difference est que la partie de programme de 
chargement OL est stockee sur un serveur eloigne 4, sous forme d'une 
w "applet" en langage "JAVA". Comme precedemment, par une requete 
"HTTP", cette "applet" peut etre chargee dynamiquement sur le terminal 1, 
en OL". Ce chargement s'effectue a I'aide de requetes posees par le 
navigateur 10, lors d'etapes preliminaires. Les autres etapes sont communes 
au cas precedent. 

15 II est clair que d'autres variantes d'architecture peuvent etre mises 

en ceuvre sans sortir du cadre de I'invention. II est notamment possible de 
charger les donnees Da dans le terminal 1 a partir de diverses sources : par 
exemple a partir d'un autre systeme informatique, connecte au terminal 1 par 
un reseau local ou par tous autres moyens telematiques. 

20 A la lecture de ce qui precede, on constate aisement que I'invention 

atteint bien les buts qu'elle s'est fixes. 

La mise en oeuvre du chargement d'une "applet" dans une carte a 
. puce par interface "CGI" d'un serveur "WEB" loge dans cette carte a puce 
presente notamment les avantages suivants : 

25 ^utilisation de formulaires en langage "HTML" standardise le 

chargement et rend les parties de programmes de chargement OL et IL a 
priori compatibles. En effet, comme il a ete montre, c'est la partie IL situee 
dans la carte a puce qui decrit, dans les champs du ou des formulaire(s) 
renvoye(s), le parametrage de chargement auquel il s'attend. 
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Par ailleurs, ce mecanisme de communication entre les parties de 
programme de chargement OL et IL permet de gerer simplement des 
sequences d'echanges dynamiques lors du chargement. 

[.'utilisation des protocoles Internet "HTTP" et "TCP/IP" pour les 
5 echanges entre les parties de programme de chargement OL et IL permet de 
les separer physiquement. Seul un routage de paquets "IP" est necessaire 
sur le terminal. Le chargement peut alors se faire dans un lecteur carte a 
puce banalise, puisque Ton conserve le protocole de communication ISO 
7816. Le terminal peut etre un simple micro-ordinateur standard connecte a 
10 Internet. 

Selon un aspect avantageux egalement du procede de ('invention, 
les applications stockees dans la carte a puce restent standards, et done 
n'ont pas a etre re-ecrites. La carte a puce et le terminal eux-memes ne 
necessitent que peu de modifications pour pouvoir accommoder le procede 
15 de ['invention : ces dernieres se resument a I'implantation, dans ces deux 
unites, d'une couche logicielle de protocole de communication qui a ete 
appelee specifique, couche logicielle incluant des agents intelligents. 

Alternativement, la partie de programme de chargement OL peut 
etre chargee dynamiquement sur le terminal, au travers la carte, a partir de 
20 celle-ci ou d'un serveur "HTTP" eloigne. 

Un simple navigateur Internet peut etre utilise comme programme 
de chargement OL. 

II doit etre clair cependant que I'invention n'est pas limitee aux seuls 
exemples de realisations explicitement decrits, notamment en relation avec 
25 les figures 2 a 12G. 

D'autre part, en lieu et place du langage "HTML", d'autres langages 
similaires, adaptes aux protocoles de communication de type "Internet" 
peuvent etre utilises, notamment le langage "XML". 

L'invention conceme aussi un procede de chargement d'une piece 
30 de logiciel dans une carte a puce a partir d'un terminal connecte a ladite 
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carte a puce par Pintermediaire d'un lecteur de carle a puce permettant des 
communications selon un premier protocole determine, le terminal et la carte 
a puce comprenant des moyens de traitement d'information et des moyens 
de stockage d'information, ledit chargement s'effectuant par la mise en 
5 oeuvre et la cooperation de premier et second programmes de chargement, 
ledit second programme de chargement etant stocke dans les moyens de 
stockage d'information de ladite carte a puce, caracterise en ce qu'il 
comprend au moins les phases suivantes : 

a/ une premiere phase preliminaire consistant a implanter, dans les 
10 moyens de stockage d'information de ladite carte a puce (2a), une 

premiere piece de logiciel (23a), formant une couche protocolaire de 
communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans les 
moyens de stockage d'information dudit terminal (1), une seconde 
15 piece de logiciel (13), formant une couche protocolaire de 

communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132, 232a) cooperant Tune 

20 avec i'autre, grace auxdits moyens de traitement d'information du terminal et 
de la carte a puce, de maniere a permettre I'etablissement d'une session 
d'echanges de donnees bidirectionnels entre au moins ledit terminal (1) et 
ladite carte a puce (2a), de maniere a ce que ladite carte a puce (2a) off re la 
fonctionnalite d'un client/serveur "WEB" ; 

25 en ce qu'il comprend une troisieme phase preliminaire consistant a 

implanter dans les moyens de stockage d'information de ladite carte a puce 
(2a) au moins une deuxieme entite logicielle {ATS, - ATS n ), apte a interpreter 
une suite destructions et a la traduire en une suite d'ordres, de maniere a 
cooperer avec ladite seconde piece de logiciel specifique (23a) pour que 

30 ladite carte a puce offre une fonctionnalite d'interface passerelle dite "CGI", 
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la dite carte a puce comprenant au moins une desdites suites d'instructions 
associee au dit second programme de chargement (IL) ; 
et en ce qu'il comprend au moins les etapes suivantes : 

1/ ouverture d'une premiere session d'echanges de donnees 
entre au moins ledit terminal (1) et ladite carte a puce (2a) grace 
auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour la transmission d'une requete pour que ledit premier 
programme de chargement (OL) recupere des donnees de 
parametrage de chargement fournies par ledit second programme de 
chargement (I L) ; 

21 ouverture d'une deuxieme session d'echanges de donnees 
entre ladite carte a puce (2a) et au moins ledit terminal (1) grace 
auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour transmettre lesdites donnees de parametrage de 
chargement au dit premier programme de chargement (OL), lesdites 
donnees de parametrage comportant une reference aux dites 
instructions associees au dit second programme de chargement (IL) ; 
et 

3/ ouverture d'une troisieme session d'echanges de donnees 
entre au moins ledit terminal (1) et ladite carte a puce (2a) grace 
auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour la soumission d'un fichier de chargement (7) prenant en 
compte lesdites donnees de parametrage de chargement, ledit fichier 
comprenant des donnees (70, 71, 72) associees a ladite piece de 
logiciel a charger (Da) ; interpretation de ladite suite d'instructions 
associee au dit second programme de chargement (IL), par mise en 
ceuvre de ladite fonctionnalite "CGI", de maniere a generer une suite 
d'ordres transmise au dit second programme de chargement (IL), a 
executer ce programme (IL) et a obtenir ledit dechargement de ladite 
piece de logiciel (Da). 
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REVENDICATIONS 



1. Procede de chargement d'une piece de logiciel dans une carte a puce a 
partir d'un terminal connecte a ladite carte a puce par I'intermediaire d'un 
5 lecteur de carte a puce permettant des communications selon un premier 
protocole determine, ledit chargement s'effectuant par la mise en ceuvre 
et la cooperation de premier et second programmes de chargement, ledit 
second programme de chargement etant stocke dans ladite carte a puce, 
caracterise en ce qu'il comprend au moins les phases suivantes : 

10 a/ une premiere phase preliminaire consistant a implanter, dans 

ladite carte a puce (2a), une premiere piece de logiciel (23a), formant 
une couche protocolaire de communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans 
ledit terminal (1), une seconde piece de logiciel (13), formant une 
15 couche protocolaire de communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132, 232a) cooperant I'une 
avec I'autre de maniere a permettre I'etablissement d'une session 
20 d'echanges de donnees bidirectionnels entre au moins ledit terminal (1) et 
ladite carte a puce (2a), de maniere a ce que ladite carte a puce (2a) off re la 
fonctionnalite d'un client/serveur "WEB" ; 

en ce qu'il comprend une troisieme phase preliminaire consistant a 
implanter dans ladite carte a puce (2a) au moins une deuxieme entite 
25 logicielle (ATS, - ATS n ), apte a interpreter une suite destructions et a la 
traduire en une suite d'ordres, de maniere a cooperer avec ladite seconde 
piece de logiciel specifique (23a) pour que ladite carte a puce offre une 
fonctionnalite d'interface passerelle dite "CGI", la dite carte a puce 
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comprenant au moins une desdites suites destructions associee au dit 
second programme de chargement (IL) ; 

et en ce qu'il comprend au moins les etapes suivantes : 

1/ ouverture d f une premiere session d'echanges de donnees 
5 entre au moins ledit terminal (1) et ladite carte a puce (2a), pour la 

transmission d'une requete pour que ledit premier programme de 
chargement (OL) recupere des donnees de parametrage de 
chargement fournies par ledit second programme de chargement (IL) ; 
21 ouverture d'une deuxieme session d'echanges de donnees 

w entre ladite carte a puce (2a) et au moins ledit terminal (1) pour 

transmettre lesdites donnees de parametrage de chargement au dit 
premier programme de chargement (OL), lesdites donnees de 
parametrage comportant une reference aux dites instructions associees 
au dit second programme de chargement (IL) ; et 

is 3/ ouverture d'une troisieme session d'echanges de donnees 

entre au moins ledit terminal (1) et ladite carte a puce (2a), pour la 
soumission d'un fichier de chargement (7) prenant en compte lesdites 
donnees de parametrage de chargement, ledit fichier comprenant des 
donnees (70, 71, 72) associees a ladite piece de logiciel a charger 

20 (Da) ; interpretation de ladite suite destructions associee au dit second 

programme de chargement (IL), par mise en ceuvre de ladite 
fonctionnalite "CGI", de maniere a generer une suite d'ordres transmise 
au dit second programme de chargement (IL), a executer ce 
programme (IL) et a obtenir ledit dechargement de ladite piece de 

25 logiciel (Da). 

2. Procede selon la revendication 1 , caracterise en ce que ledit lecteur de 
carte a puce (3) et ladite carte a puce (2a) comprennent des premiere et 
deuxieme piles protocolaires pour lesdites transmissions de donnees 
selon ledit premier protocole determine, definies par la norme ISO 7816, 
30 chacune comprenant au moins des couches protocolaires de 
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communication logicielles (101, 200a), dites basses, de maniere a 
permettre lesdits echanges de donnees entre ladite carte a puce (2a) et 
ledit terminal (1), ces couches formant interface avec lesdites premiere 
(13) et seconde (23a) pieces de logiciel specifique formant lesdites 
5 couches protocolaires de communication specifiques, respectivement, et 
en ce que ces pieces de logiciel (13, 23a) comprennent chacune deux 
entites supplementaires constitutes d'un module de transfer! de donnees 
(130, 230a), formant interface avec lesdites couches basses (101, 200a) 
des premiere et deuxieme piles protocolaires, et d'un module de gestion 
10 (131, 231a), et en ce que lesdites premieres entites de chaque paire sont 
constitutes de modules logiciels, dits agents intelligents (132, 232a1) 
etablissant lesdites sessions. 

3- Procede selon la revendication 2, caracterise en ce que ladite suite 
destructions a interpreter associee au dit second programme (IL) de 
15 dechargement est constitute par un script et en ce que ladite deuxieme 
entite logicielle est constitute par un module logiciel dit agent intelligent 
traducteur de script (ATS, - ATS n ) fournissant des ordres comprehensibles 
par ledit second programme de chargement (OL). 

4. Proctdt selon la revendication 3, caracttrist en ce que ladite premiere 
20 ttape comprend (Emission d'une requete de type dit "HTTP" selon un 
protocole de type Internet par adressage d'une page determinee en 
langage "HTML" contenant lesdites donntes de paramttrage, ladite 
adresse ttant une adresse de type "URL" de rebouclage sur ladite carte a 
puce (2a). 

25 5. Proctdt selon la revendication 4, caracttrist en ce que ladite deuxieme 
ttape comprend renvoi par ladite carte a puce (2a) d'un formulaire (8, 8') 
en langage "HTML" et en ce que ledit formulaire (8, 8') comprend au 
moins une adresse de type dit "URL" de rebouclage sur ladite carte a 
puce (2a) et un chemin menant a un repertoire dttermint contenant ledit 
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script associe au dit second programme de chargement (IL), de maniere a 
ce que ce dit premier programme de chargement (OL) recupere les dites 
donnees de parametrage. 

6- Procede selon la revendication 5, caracterise en ce que ladite troisieme 
5 etape comprend renvoi d'une requete de type dit "HTTP" a ladite adresse 
"URL", designant ledit repertoire contenant ledit script associe au dit 
second programme de chargement (IL), ladite requete comprenant 
lesdites donnees representant ladite piece de logiciel a charger (Da), 
('interpretation dudit script et Texecution dudit second programme de 
w chargement (OL), de maniere a obtenir ledit chargement de la dite piece 
de logiciel (Da). 

7. Procede selon la revendication 6, caracterise en ce que ladite piece de 
logiciel (Da) est une appliquette ecrite en langage "JAVA" (marque 
deposee). 

15 8. Procede selon la revendication 7, caracterise en ce que ledit fichier de 
chargement (7) est incorpore dans ledit formulaire (8, 8') et comprend une 
entete (70) identifiant ladite appliquette, des donnees (71) et au moins 
une signature electronique (72) obtenue a partir du chiffrement desdites 
donnees. 

20 9. Procede selon la revendication 8, caracterise en ce qu'il comprend au 
moins une premiere etape supplemental, realisee apres ladite troisieme 
etape, et en ce que cette premiere etape supplementaire consiste en 
I'ouverture premiere session supplementaire d'echanges de donnees 
entre ladite carte a puce (2a) et au moins ledit terminal (1) pour 

25 transmettre un code predetermine regu par ledit premier programme de 
chargement (OL). 
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10-Procede selon la revendication 9, caracterise en ce que ledit code 
predetermine consiste en un acquittement iorsque lesdites trois premieres 
etapes se sont deroulees correctement ou un code d'erreur dans le cas 
contraire. 

H.Procede selon la revendication 10, caracterise en ce qu'il comprend au 
moins deux etapes supplementaires, realisees apres ladite troisieme 
etape, comprenant I'ouverture de sessions d'echanges de donnees 
bidirectionnels entre ladite carte a puce (2a) et au moins ledit terminal (1) 
pour la transmission d'un formulaire supplementaire requerant la 
soumission de donnees supplementaires. 

12. Procede selon la revendication 11, caracterise en ce que lesdites 
donnees supplementaires comprennent une signature electronique 
supplementaire. 

13. Procede selon la revendication 12, caracterise en ce que ledit terminal 
etant connecte a au moins un serveur eloigne (4) via un reseau de type 
Internet (Rl) et par la mise en oeuvre de protocole de communication de 
type Internet, un desdits agents intelligents (132) est associe a un attribut 
dit de "reseau" permettant des communications avec ledit reseau Internet 
(Rl) et en ce que ledit premier programme de chargement (OL) est stocke 
sur Tun desdits serveurs eloignes (4, 4a). 

14. Procede selon la revendication 13, caracterise en ce que, ledit terminal 
(1) comprenant un navigateur de type "WEB" (10), ledit premier 
programme de chargement (OL) est constitue par un composant logiciel 
dudit navigateur "WEB" (10). 

15. Procede selon la revendication 14, caracterise en ce que ledit composant 
logiciel (OL") est obtenu par une etape initiale de chargement dynamique 
d'une appliquette (OL) ecrite en langage "JAVA" et stockee dans ladite 
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carte a puce (2a), ledit chargement etant obtenu par remission d'une 
requete de type "HTTP", avec un adressage de type "URL" de ladite carte 
a puce (2a). 

16.Procede selon la revendication 17, caracterise en ce que ledit composant 
5 logiciel (OL") est obtenu par une etape initiate de chargement dynamique 
d'une appliquette (OL) ecrite en langage "JAVA" et stockee dans un 
desdits serveurs eloignes (4), ledit chargement etant obtenu par remission 
d'une requete de type "HTTP", avec un adressage de type "URL" dudit 
serveur eloigne (4). 
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